I personally find the very disconnected nature of the teams I lead in my consulting work actually forces us to communicate in an open, concise, discoverable way that would be good for any type of team, but that co-located teams get to cheat out on because a weak team member can always ride his stronger teammates' organizational coat tails with nosey interruptions and annoyances.
We have to think things through and write clear specs, because we can't use body language to clarify and count on the people involved in the meeting to just remember the attitudes expressed. We have to be good about change management, because we can't just turn around and ask someone to "get out of a file" or do whatever we want to the database whenever we want to. We have to keep meetings to a minimum, because you just can't have a productive, two-hour phone call.
These are all good things for non-remote teams, too. But they cheat and don't follow good practice.
1. Have the key folks (leads/project managers) travel and stay with team for at least 4 weeks in a common place.
2. Do not force video (leave the mode of comms to peoples preference (video / email / call))
3. Allow decision to be made over text chat and have it added to project decisions in weekly meetings
4. Identify couple strong people per 15 members team and have relationship where they will tell you before deciding like 6 months in advance and allow people to leave. They will come back later. And wholeheartedly develop them even if you know they will leave, with one condition that they will develop one more person like them for the team.
5. Have good leader in India who can speak open with out fear of a westerner (I find this a most difficult one). This is a real deal maker between peace of mind and micro managing and going crazy.
6. Be open t listen to same idea that your team thought and decided to ditch from your offshore partner. (we can go for full blog post on that)
I think this would take the team long way. Please remember either USA side or India will have to lose 3 evenings a week, irrespective of SRS, Comm tools and so on if you need a successful delivery.
* hate meetings
* prefer slack/hipchat/etc even if seated adjacently (myself included)
* work asynchronously
> My job is in sales and I am teaming up with "sales" engineers. The bottom line is that they have the technical knowledge and I just have to manage/prioritise the relation with the Customer.
>>> I am doing the meetings instead of them
>>> They don't like to be disturbed while producing, or move from their chair >>> hipchat is the best option for me
>>> they are dedicated on different tasks/projects
So, when they are working remotely is fine for me as long as us don't loose the intimacy [common language]
IMHO it is not hard or difficult per se, but you need to design your company around it, like with other things.
It is also an area that needs more study in order to develop fully.
Probably if I had a conventional company and I had to transform or convert it to remote, it wouldn't work. There would be vested interest against the conversion on some people, some people would not believe it is not possible(people tend to believe that if you don't look busy to others you are not working) or managers will fear their employees slacking.
When you create a company that makes money from day one remotely, you have not this problem, as you organize around it and it is not optional.
In some ways it is weird. If you go out of your house to get your children from school because you did not spend 1 hour commuting to work, 1 returning from it, society could believe you are not working at all.
They are often surprised to see you have money, and much more money than they have.
But I suppose it is not different from an old farmer watching people sitting in a chair in the city call it "work".
Oh man, I run into this constantly. I think my in-laws may have finally gotten over it, as they probably figure their daughter couldn't have afforded three international vacations this year on her own.
I don't tell people I've cut my hours back to 20/wk. Most of the people I know just aren't ready to hear "I work less and still make more than you."
Some minimal time-zone overlap is never overrated. I think it is hard to beat real-time communication over chat or voice - asynchronous delays break up any flow in collaboration and turn it more into throw the requirement over the wall and listen for an echo the next morning.
"as a product you’re betting that your API design is robust enough that groups can remotely work at their own pace or velocity. The core question is why would you want to constrain yourself in this way? "
I am not certain which constraints are implied here - to me an API that facilitates such a work is simple and understandable which to me are admirable qualities.
Perhaps the challenge then is to split the architecture into small enough testable units which communicate through the simple APIs? Once again, this sounds great.
But in practice simplicity, understandability and good architecture are reachable by experience or trial and error so I suppose it would require either a situation were a known pattern is reapplied to new business requirements or one where there is ample time for designing and prototyping with these qualities as explicit design constraints.
"how to balance resources on each side of the API."
I suppose the best situation would be then an API that supports a directed graph of rensponsibilities. Like a plug in system, for instance?
"...however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. "
So I suppose to make remote working work software architecture and team management need to be linked on a very intimate level? This would be nice in any situation, I think
I think the author is a bit out of touch with how startups operate. Personally I'll take a crack team made up of five best people sitting in San Francisco, New York, Berlin, Bangalore and Tokyo over a special team with a powerful corporate mandate ensconced in Microsoft's Redmond campus.
If everyone is good at what they do and has their eye on the ball, then communication can be managed from anywhere, but if you're dealing with the political reality of operating in a major corporation then you need all the help you can get.
I find it interesting that I myself am all for remote workers, but have had nothing but horrible experiences with workplaces where everyone has their own office. Pondering this a bit I think it's because every workplace I've been in with individual offices (Microsoft and others) also seemed to be very old school in terms of communication software.
I think this is true of any organization, geographically divided or not. These are the challenges of organizational structure, and I've seen them affect organizations in a single location just as much as organizations with remote engineers.
In my mind, the single most important thing to do is to re-evaluate and adjust the structure early and often. The way you divide up work today will almost never be sustainable - regardless of geography. The trick is to help everyone understand and expect those changes to occur frequently.
Of course if they live in a first world country you can probably sue them (and hopefully it could refrain them from releasing your code) but if they come from countries where the law is an abstract concept there will be no brake to exacting their revenge.
Efficient dev environments can't be totally locked down, because often people need to experiment with some parts of the environment (for example to reproduce bugs that only happen in some environments).
When you tell them they're fired you can block them from physically accessing their dev machine.
Of course if you work on an open source project this problem go away, every employee is mandated to release their code ;-)
So I think you're underestimating the likelihood of employees copying code (it doesn't take anticipating being fired), and overestimating the impact it would have (it really won't do a damn thing).
Every job I've had, the project code has somehow ended up on my personal computer. It has been a combination of factors. Generally, it goes that I get sick and declare I'll work from home. Either the company had provided a laptop or they hadn't, in which case I would have to use my personal PC to work. If a laptop was provided, the hardware was slow, or the tools installed were not my favorites (or particularly bad), or issues with the VPN connection/antivirus/corporate spyware software made everything slow. So in almost all cases, I've ended up with everything copied anyway.
And when I left the jobs, I had immediately deleted it. But even if I hadn't, even if I had taken and used the code (illegally), it really wouldn't have impacted the company. It's not like I would have been able to approach the clients and gotten them to go with me: typically the client owns the code anyway, I wouldn't have needed to copy the code. It's not like I could have started a competitor all on my own off of the company's own code base. And finally, the vast majority of projects just aren't that novel: why would I potentially throw myself into a den of thieves and lawyers for what is probably a crufty POS that I could replace in a weekend of caffeine fueled mania?
 oh, except, you know, not forcing your team to be co-located.
 This leads me to believe you are probably more the businessy/MBA type, rather than the engineering type. It's usually the MBA type who is most fearful of someone stealing the IP. The engineers who actually make the IP rarely consider it a threat.
Sorry to disappoint I'm of the engineering type. I'm also of the paranoid type though ;-)
I'd be interested in seeing/reading about cases of good "greenfield" projects where major architectural decisions weren't made almost exclusively by a relatively small number of people, particularly if the number consisted of more than one digit.
 subjectivity aside
I'd love to see negating or supporting data either way, it's just my opinion that if you want a team of engineers (as opposed to a singular dictator) to build you something amazing (C Language, SR-71, Saturn V) they need to be in the same physical location and see each other face to face.
Of course we all own a telephone, so the instantaneous-ness is always there. But timezones create a mandatory delay to availability which can't be easily worked around. So whereas people are normally very accustomed to working via a continuous flow of real time communication, they now have to learn to communicate via delays and compartmentalize decisions and production.
Some people can't deal with this. So they start to find ways of splitting up work by location. But eventually, things get out of sync, because they never learned how to communicate in a new way. This then creates things like a mandatory daily meeting just to figure out what's changed in the last 24 hours, or red tape designed to keep people from making decisions on their own, or a lack of any kind of tape, or a breakdown in leadership, or the inability to accomplish tasks independently, or lowered morale, etc. This lack of being able to cope with communicating and working asynchronously is, I believe, a sort of stagnating death spiral that (without seriously competent self-starting workaholics) just results in mismanagement and tepid progress.
As a contrary example I like to use the open source development world. They work on different parts of different projects in different regions all the time. They self-organize and come to consensus quickly, and are led by a small team of well established hierarchy that makes quick, decisive executive decisions. There is basically no bone-headed executive level muddling with your work, nor contemptible middle-managers fighting for power, nor tepid low-level engineers waiting for someone to make a decision. Everyone just gets shit done because they all have one goal: to ship a good product. That's all very nice because you aren't part of a corporation, and you feel like your contribution matters more.
But in a corporation, you have to deal with all the usual corporation bullshit, in addition to now working asynchronously. I think this is where the big breakdown occurs in practice; two different sets of problems (asynchronous communication, and corporate bullshit) add up to a more complicated way of working. If you're very lucky, everyone will be able to work the same way and things will go smoothly. But in practice, not everyone works the same way, and thus bugs crop up in the work due to process incompatibility.
So why is remote engineering difficult? It's not; it's just a specific skillset.
I think one of the big differences I noticed is that I never felt like I was that close to the rest of the team. We talked a few times/week through Webex or Skype, but it's just not the same as being there in person.
Communication was also a big issue. It's not impossible to have good communication remotely, but I've rarely seen it in practice.
Also, to the best of my knowledge nobody applied telepresence directly as a bonding tools - it's mostly used for straight work, because(at least the cisco versions) are quite expensive.
In a work environment people stay on global and per-team IRC channels. You can a) chat online if there are colleagues online and b) when you get back from your coding session you can always review what others have been talking about since yesterday. You can also chat in a relaxed way as in replying back every 10 minutes or whenever you don't have more important things to finish. This means you can extend your online presence over the workday with a latency of checking back several times an hour while still not getting bounced by each and every message someone decided to send you.
I was never part of many of the decision-making meetings with the boss and my project manager and I felt like the manager never had our back. After we met onsite for our first bi-yearly 1-week meeting, I realized that he didn't really have any choice in the matter and did in-fact fight for us when these decisions were made.