I had an experience this year which made me aware of some of the ways that remote work can go wrong. Although in my case my work was not "remote" in the sense of being away from the office (though sometimes I worked from home). My work was "remote" in the sense that the tech team was all in one office in London, and I was the first programmer they hired in the New York office.
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.