Lessons from 2 months of remote working
iamnotaprogrammer.com
iamnotaprogrammer.com
I remember a few months in when it really sunk in that I was actually working out of my home. My house was my office and my office was my house, and everywhere I went I could not get away from work. I had a sudden feeling that the walls were closing in. Lucky for me that went away, and I find that I get more done and am able to be more focused than I was in an office.
A few pointers to those starting to work at home:
1. If you are like me and tend towards being a work-a-holic, working from home can mean turning your normal 8-10 hour workday into a 24-hour workday. Set limits and work by them get...
2. ... a home office where you do your work. Make sure it has a door which closes and treat it like an office. You don't have to work in it 100% of the time, but it helps me to have a place I can leave my work. My office is great - I have a big desk, a couch, music, big windows. It is the office that I would like to work in.
3. Get out of the house. Not to work, but to play. Get around people. It is going to happen - you are going to have a crazy project and find yourself locked in your room for a few days. This is pretty normal, even in a normal office. It can easily become your life since there is no one telling you to go home.
The perks of working from home are great - no commute means more family time, and the you get a personal bathroom and kitchen. If you need to take a 20 minute nap no one is stopping you, and going for a jog is as simple as opening the door and taking off.
This is one thing I didn't like when working in an office. At my last office role we had team chat, but nobody used it, they just walked over and interrupted you if they wanted anything. Happy and free now :)
But most of them can't have a reliable Skype call. We still have issues calling from Australia on a decent connection to a similarly decent connection in the states.
What we've found - Good connectivity that can hold a reliable Skype or Google Hangout conversation is essential - don't be fooled thinking you can achieve this at a random Internet cafe in Cambodia. You might be able to (!), but plan accordingly.
What's a major city? If we're still in the coarse-estimate mode, I'd say a city most people have heard of.
Maps of internet backbones will help you locate the ideal places, from a connectivity point of view.
In many places, a 3G or 4G backup works amazingly well. Certainly here in Australia, and probably in certain places in Asia/Europe too.
They break you out of a flow and bind you.
Chats/Forums/Emails are easier to integrate into the day.
The advantages are too awesome! I get to spend more time with my daughter (I'm a first-time father and she is just turning a year old today). There is hardly anything in this world that makes me happier than spending time with her. If I had to commute to work every day I'd basically see her on weekends and miss out on her every-day life. My parents did that. It sucked for them I'm sure and it would suck for me too.
I am a software developer and so my work is primarily categorized as, "knowledge work." This is a very post-industrial job. Working more hours does not directly produce more "product." Working remotely allows me to take a walk and do some groceries while I mull over the dilemma that has been bothering me. Often I will come back refreshed and with a clear solution. Or I can read a book to my daughter while I think about it. My job requires thinking and generating good ideas (which is a process that requires idleness and spontaneous connections through hunches). A 9-to-5 policy of being in a seat and typing away is not very conducive to developing software (unless you're applying the Shakespeare Monkey Method).
The OP mentioned the disadvantage of spontaneous social engagement. That is a problem I can attest to. However it is one I am willing to give up. I'm not as young as I used to be and it's not terribly important for me to play ping-pong with my co-workers and talk shop over beers. We make up for it by talking shop online during office hours and there are tools such as Sqwiggle which make those spontaneous chats possible.
At first this problem seemed big. I went out less and suffered a lapse in my social graces as a result. However I learned that I was just doing it wrong. Now I find I socialize more than I used to because I'm out in my community working out of coffee shops with other people in the same situation as I am. I meet see local people and we do local things and I've learned to develop a village mentality.
The real challenge for companies engaging remote workers is letting the reigns off. The fear of idleness is a rapacious concept amongst managers and entrepreneurs. You can hear it manifest in expressions such as, "always be hustling," "fail fast, iterate," and the like. However if history and open source have taught us nothing else it is that the condition of the human spirit is towards accomplishment. The goal in finding good people to work with is finding people whose sense of accomplishment shares the same spirit as yours. Even in idleness we unconsciously reach towards that which inspires us.
Remote work is great. Being around people in person is great. We live in a world where this is possible and easy to manage. There's no reason to force people to adopt your standards of living and geographic preferences to work with you.
(We just may be limited to certain national boundaries for the most part due to taxes and the inconvenience of international banking, but hey... walk before you run)
Update
The biggest challenge for remote workers is working with a centrally-located team. The styles of communication need to be more rigorously defined and a part of everyone's habits or else it tends to fall apart. The central team tends to isolate the remote worker because they're so used to just having a hallway chat and forget to share that with the rest of the team. To avoid this everyone needs to agree to share all information and to make it a habit to strike up email threads, create issues and log chats in IRC/Campfire/whatever. Important issues cannot be decided face-to-face over lunch and not documented somewhere. It just doesn't work that way when you have remote workers.
The tools to make communication between remote teams have been evolving at a rapid pace in the last few years. WebRTC, shared documents and better issue trackers... there's almost no excuse anymore not to adopt these habits even if you are a centrally-located team. And if you do adopt these habits there's nothing getting in your way from incorporating remote workers anyway.
Thanks! -Matt (Co-founder)
Exactly! I've always wondered why people are pushing the American death march way of work - long hours in an office and no work/life balance. I really hope we'll be able to change that and make remote work and other unusual work schedules more common in Europe. There is nothing better than going out for a walk in the middle of the day if you are stuck on a problem or starting your work day at 12. Lack of pressure and stress == higher productivity and better health.
Also, spot on with the biggest problem, working with an otherwise centrally located team.
My biggest issue is that, and also the fact that while my office is technically in Mountain View, my home (and hence, primary work location) is in the Annapolis, MD area, a few hours removed from theirs. As a result, while much of my time is respectful of the time difference, every time I work with someone new, or less considerate, I invariably get calls when I'm just sitting down for dinner, or 10 minutes after I've arrived at a bar, etc.
I don't generally mind, but I always worry about the perception every time I'm actually unavailable and that if it happens enough, I'll be seen as problematic. I'm told I'm overthinking it, and despite the fact that I'm generally more productive than the dev team sharing an open office plan, a lot of that advantage is mitigated by having to wait on meetings, etc.
The amount of code written doesn't mean as much.
There simply is no meaningful correlation. It usually takes the talent of another skilled professional to measure the quality of your work, which is one of many reasons why management exists.
In general though I am motivated by accomplishment. I feel good about doing a good job. It is its own reward. I feel that I've had a good day's work when I've contributed something worthwhile that has improved the code, the company or my team in some way, even if it's small.
I keep my work days structured around the traditional 9-5. At first it was out of habit but I've since embraced it as a discipline. The difference for me, I believe, is that without a long commute and being stuck in an office far from home there is very little cost associated with following "sporadic" opportunities. I don't leave time out for them because the benefits tend to out-weight the cost of being away from my desk. I can get up and take a walk down to my local café, chat with the barista about local events and pick up some flowers for my wife on the way home. This relieves stress, breaks up monotony and gives me time and space to connect the hunches together in my mind. I may come back from that outing with the solution to my problem or I may not; but at the very least I will be reinvigorated to take on the next set of tasks ahead of me and it cost the team almost nothing and gained quite a bit.
The way I see it my employer was looking for someone who was smart, experienced, creative and responsible. I do everything I can to cultivate that in myself. They're not paying me to trade hours for lines of code. They need someone with my experience, knowledge and intuition to help them solve problems and build a solid product.
If the solution to our problems as programmers could be solved by rote then I'd be out of work and in a different profession.
An excellent way to address this problem is to have a co-founder, preferably a technical one, be remote.
Given that this person is important, they will notice if they are being left out and have the weight that their complaints are heard. If no important person is remote, then these things slip far more easily.
There are several minor reasons why I'd prefer to see a senior technical person be remote. The first is that quiet time without interruptions is more likely to benefit the technical person. The second is that a non-technical co-founder has more interactions where they are likely to have legitimate reasons to be in the office.
But if it works better for you to have a technical co-founder in the office, and a non-technical co-founder who is basically a roving salesman, then go for it.
Of course, we all know that all the good programmers live in SF.</sarcasm>
I find commuting and all it's associated challenges exhausting (traffic, public transit, parking, etc)
You also have to factor in how tired you are when you start to actually work.
I do miss out on human interaction and being able to bounce ideas of co-workers.
Do those things from home, then decide whether you're more productive than at the office. Otherwise you're not really comparing apples to apples.
- you're definitely more productive when working from home and it saves a lot of time
- communication is much harder
- traveling and working is difficult and I would not recommend it
- working from home is a bit depressing over time and you can easily lose touch with the team
For me what works best is a mixture of the two.
1. Massive sense of freedom - you own your time, and it's yours to be productive. YesGraph (my employer) is results based, and not hours-based. This is awesome as a remote employee.
2. Exercise isn't Easy - I used to walk over 2 miles/day to work, so I have to force myself to get enough exercise during the course of the day.
3. Tendency to Overwork - I'm being very proactive about trying to balance work. It's easy to fall into the trap of working too much (especially with 2 hours saved on the commute)
4. Social Interaction is Important - this is really important internally and externally. If I want social interaction outside my job, I simply need to go to a coffee shop or co-working space. It's important to do this internally too - which means doing hangouts with fellow employees.
I've actually been keeping detailed notes on my productivity (using Rescuetime) and exercise (using Fitbit), you can track my progress here -> http://lukethomas.com/working-remotely-tracking-progress/
We actually had an onsite last week, so I have some data to benchmark remote productivity vs. onsite that I'll publish soon.
Do you have solutions for them?
There's a cost for most businesses to being in different countries. Typically, for larger businesses, finance and HR pick up most of the slack here. Having 17 employees potentially in 17 different companies feels like it might be a bit of a logistical burden. Any counter experiences?
I recently moved to a country with a low cost of living whilst continuing my old webdevelopment role as part of a remote team.
Some things that we do:
- daily short standup on google hangout
- everyone is available on an instant messenger when working
- every office/home office has a continuous webcam feed going on over google hangout
- remote pairing (not the biggest myself)
We've talked about doing this with my all-remote team, but it seems incredibly invasive. How has your experience been?
It felt a bit like sitting at an office, people can look at me there as well.
I think WFH isn't a good idea for a junior dev (e.g., <5 yrs experience). In my career, I've learned the most from working closely with really smart engineers, and doing CRs over email isn't sufficient to soak up that knowledge. Standing at a whiteboard and arguing about design patterns for an hour, sitting at the same computer crafting a new API, etc., are the best ways for you to learn quickly.
It's also important that you work on a team with smart engineers for the above to be valuable. If you have no CR process, or don't have any devs smarter than you, then there aren't any downsides to WFH, but that's only because the above upsides aren't there.
We (getblimp.com) are currently working to consolidate real-time chat with task management in a very unique way. This will allow remote workers to collaborate freely on chat and then move those conversations to a more persistent form, a task with context.
http://blog.getblimp.com/2013/11/blimp-needs-more-bandwidth/
That might be something you also want to consider offering in your solution, as an additional method of accomplishing the same thing.
Any HN'ers have any experience or stories doing something similar?
I'd recommend scoping out short term apartment rentals or the like (Airbnb might be a good bed). That way you might be able to get better internet access, as well as access to a host that can give you advice on exploring the city/country you're in.
If I were you I'd stay more than 2 weeks though, 4 weeks seems ok, 2 weeks while travelling doesn't seem enough to see everything. Granted that I never worked while travelling but that's how I'd do it (and also stay longer than 1 month if I really like a place)
Also, I'm starting my own company and reading this helped me understand how others do it. I'm glad this is working out and hope that more people figure this out.
Many companies I've worked for have this outdated mindset that you need to be in an office together in order to make things work. The reality is you don't. Yes, you miss out on some of the local stuff that an office can provide. Like drama, politics, and petty bickering. But I would rather bitch about someone from home......in my jammies. :)
However we have also found that having a spread out team can lead to increased collaboration and outreach as people go to seminars/meetups etc locally. It is also nice that people who are normally in the office can easily participate in meetings when traveling or staying home for whatever reason.
Before I get into the details, I'll offer some qualifiers: I could have done more to communicate with the management that I was not getting the information that I needed. I could have been more pro-active about forcing people to answer the questions that I needed answered. Having said that, I think some of the miscommunication that arose might be common when companies first try either remote work, or simply work that occurs outside of the main office.
I was hired by a large media company. I worked there from January 2013 to August of 2013. The company has about 25 programmers in the London office, plus a QA team and project managers (and the CTO and CEO -- all upper management is in London).
The first month I was there I worked on some projects using functional languages like Clojure and Scala. I needed to ask a lot of questions about the internal API. After awhile, the management decided that I should have a single person that I could contact with questions. I'll call him Jim -- he was a super smart guy and a dazzling engineer. For the next week, he was able to answer all of my questions about the internal API (indeed, Jim had created most of the API). However, the 2nd month I was there it was decided I should work on the company CMS, which was written in PHP. Jim did not know PHP, and he had never worked on the CMS, so he was no longer able to answer my questions. No one else was ever assigned to me as my point of contact.
Informally, I later defaulted to sending all of my questions to the woman who lead the QA team. She could rarely answer my questions but she often knew who could, so she would redirect my questions to the right person. The only problem with this system was that it was slow. Especially given the time difference, if I asked a question at any point after noon, the earliest I could expect a response was the next day. And then, towards the end of my time there, the woman quit. (That was another problem I faced -- there was a lot of turnover in the London office, so even once I had established an email relationship with someone there, they then would suddenly disappear.)
I recall trying to setup the CMS to run on my local machine. I kept getting a strange error regarding dependcies. I looked in the git log to see who was the last person who had made changes to the way the system handled dependencies. There were 4 people who had recently touched the system. I wrote an email to all 4 of them, explaining that I was trying to set up the CMS, and I kept getting this error. One of them replied "Come over to my desk and I'll help you." I was like, uh, I am in New York, I can not come over to your desk. Everyone was surprised that there was a programmer in New York.
Four months later I got another error which I traced back to dependencies. I re-did all the steps for upgrading the dependencies, but now nothing worked. I wrote to several of the programmers again and asked them if they had any idea why things were not working. One of them wrote back, clearly irritated: "If you simply read the announcements, you would know that we changed the dependency system this week." I asked, what announcements? He replied: "The ones posted to the tech mailist." I asked, what tech mailist? I was told that there was a mailist and every programmer was suppose to be on it -- it was the main way annoucements were shared with the whole tech team. For me, it was like having a whole new aspect of the company explained to me. I was finally put on the mailist and started to get the announcements. By this point I'd been at the company 6 months, and by this point I had already complained many times that I was not getting enough information about what was going on in London. It seemed strange that no one had thought to suggest this before.
At some point I was given the assignment to add some serious functionality to the CMS. I was given one month to do it. Despite working some long hours, I was 5 days late getting "done". But I was not done. I sent it to the QA team and they sent it back -- there were some edge cases where things were failing. I fixed the code to handle the edge cases and sent it to the QA team. They sent it back again. This went on for another month. By the time my code went to production it was over a month late. Part of the blame surely lies with me, but part of it was the slow speed with which information was communicated. The QA team would tell me about some edge case, but I would need to ask dozens of follow up questions to understand why the edge cases were in any way relevant.
In many ways, this job was the best job I've ever had: good pay, great people, a relaxed culture. Every Friday we had "Beer Friday" meaning people quit early and we broke out the drinks. The New York office was full of talented writers and creative people.
All the same, the whole time I was there I was concious of being an experiment. The company thought it needed to have a tech team in more than one time zone. But for me, getting needed information was like breathing through a very small straw -- I never got enough. I found it difficult to find the right balance between asking too many questions via email versus reading (out of date) pages on the wiki versus digging through git commit notes to see when a change had been made.
In the end, I decided to leave, because I did not feel that I could do a good job. I am sure I could have done more to get more information out of the folks in London -- it does not speak well of me that I gave up after a few months of trying. All the same, I think there is some lesson in this: if a company has the tech team centralized in one office, and then the company decides to expand the tech team beyond that one office, then some real changes in workflow are needed to make that work.
What tends to happen is decisions get made that remote people get left out of and they get communicated verbally rather than through the normal channels. It's really important that the company plans around the remote people. I've heard from lots of companies that they've ultimately canceled remote work when there's just one person remote. It's a bit too hard to break out of bad habits.
This is a great cautionary tale for teams who are thinking about adding one or two people remote when they're all in one place.
That's a huge red flag imho. I don't think your experience speaks against remote work in particular: it's a just a communications problem between teams / departments, and that's very common in most companies.
"2.5 billion people in the world have internet access.
Statistically speaking, the chances that the best person
for us to hire for any position is among the 0.023 billion
people in the New York metro area is unlikely."At least when I was thinking about it, I wanted to convey the sheer magnitude. New York is the largest city in the US (8m), but I used the metro area (23m) as my population size. But even with all the people in New York, we'd be limiting ourselves if we say "You must be physically nearby". 2.5 bn with internet access seemed to convey the scale of things - albeit imperfectly.
What would you recommend is a better way to do it?
"2.5 billion people in the world have internet access.
Statistically speaking, the chances that the best person
for us to hire for any position is among the 0.023 billion
people in the New York metro area is unlikely, even
considering the high concentration of talent in New York."