Any recommendations or experiences you can share- what works, what didn’t work?

Thanks!

Does anyone have any recommendations- real time updates is key as our calls are on skype/ghangout.

Thanks!

I actually used to work at Morgan Stanley, which was navigating a pretty dramatic shift from horizontally scaled to fully distributed (at least, for certain IT teams, including mine at the time).

We had team members in New York, Montreal, and India. The New York – Montreal team was the bulk of the engineering staff, but there were serious issues with out-of-band communication, both within the Montreal office and within the New York office. Even I was guilty of this, not knowing much about the dynamics of distributed teams at the time. Of course, with the India team, there were serious problems with navigating the timezone delta. In my current startup, I try to solve both problems by forcing 100% of the team onto web-preferred communication, by centering the team roughly around EST time (with “core hours” of 10am-3pm ET), by enabling full transparency, and by having regular team retreats.

It was actually at Morgan Stanley that I learned the importance of asynchronous communication. We had an always-on chat room with good etiquette re: backlogged messages and status messages. We also had a strong culture of technical discussions via e-mail and using code prototypes. So I’ve definitely seen large companies dabble with moderate success. Just like anything else at BigCo’s, though, it takes a lot more to drive organizational change than it does at nimble companies that were only recently founded.

Re: “work-from-home flexible arrangements”, I really see that as something else altogether. Few vertically-scaled or horizontally-scaled offices are willing to adopt the “distributed team culture” merely to enable people to occasionally take a work-from-home day. This is perhaps a good thing — doing so would probably alienate a portion of the workforce who sees no need for work-from-home flexibility at all (or views it as nothing more than an occasional “perk”, another side of the “flexible hours” coin).

I think it’s instructive to view “face-to-face preferred w/ flexible work-from-home arrangements” and “digital preferred w/ no requirement for office presence” as fundamentally different cultures.

@Devdas, I think the analogy to kernel development conferences is a great point.

The switch needed for the companies to flip is between synchronous and asynchronous modes of communication. Once you start communicating in a form suitable for asynchronous communication, distribution becomes a lot easier. You want something with extremely high SNR, rather than high bandwidth. Hence text over voice/video. Then you sync up every few months to bring up areas of focus (kernel development conferences, for example).

This is the same technical insight as RPC vs message passing over sockets. For the tech types, CORBA vs Erlang.

An interesting angle on the question is how viable it is for companies to shift between different models.

Some of the best examples, Automattic and Github, started fully distributed, and it makes sense that as they’ve done so well they’ve grown with those models. But I know of few established companies that have tried to make the switch.

Many large companies like Cisco, IBM, Accenture, etc. all a lot of remote work but on a daily basis – where people work from home a day or two a week. The gap in the outline you have is there’s no easy place to categorize these companies, even though they probably represent the largest numbers of remote workers in the world.

The purpose of my blog post was to identify and describe the three models I am seeing in the wild.

I know that horizontally scaled teams have some serious communication issues, typically, for the reasons you outline. Personally, I only consider vertical and fully distributed to be viable scaling models; any attempt to go from vertical -> horizontal should probably be a shift from vertical -> fully distributed, instead.

Teams that are fully distributed (i.e., option 3) don’t have this problem (at least not the same extent) because there is no headquarters. However, care must be exercised to ensure that workers in any one office or region don’t fall into this trap as each sites scale vertically (i.e., option 1).

Great read. I recently presented similar ideas that came from my own experience – “Visibility Shift in Distributed Teams” http://prezi.com/lrosc_z0pzy0/visibility-shift-in-distributed-teams/

I believe that working in a distributed environment is like using Scrum – it does not solve your problems, but makes them more visible.

Couple of things:
- Full distribution works only for those who can organize their time. They’re definitely not juniors, they probably don’t have their family at home (to distract their concentration), etc.
- Since this working method is so young, we can’t know the impact of distant teammates to our “business social life” (as opposed to “private social life”). I know it by experience that it boosts efficiency a lot to meet distant coworkers every now and then and work together at the same location for a while.

Other than that, full distribution is really here and it’s a viable working method indeed.

“Another thing which makes a distributed approach difficult to implement is the stress or extra work load on managers to keep thing “in sight”. Many managers like to see their workers on their chair and “manage” on-site.”

Fire those managers. If yours is a creative organization of any kind, those managers are worse than useless — they are actually harmful, and will have a net negative impact on your team and its overall productivity.

A question was asked, How do you track worker’s time? Answer: We don’t need to. Worker pay is tied to expected throughput. The business is so small, everyone knows everyone else. If you are not paying people by the hour, you need some sort of work delivery tracking system. A ‘results-oriented’ work environment.

Programmers in such an environment would need their work tracked by meaningful value delivery metrics. I think that would be an improvement over pay by the hour. But it would have to be a fair and accurate measurement. I’m not sure how it would be done. It’s not always easy to isolate individual contributions to a team project. Project milestones might be used as a collective measure of value delivery.

having a distributed team is great and allows us to cherry pick our development team based on the best people instead of the best people in a given geographic area. only caveat is that people in a given timezone/region should always have at least one other person with whom they share a work schedule. our australian dev doesn’t have much company when he’s hacking.

For example, a few friends of mine actually like working in an office.
Another friend of mine told me he’s setup a fully distributed environment at some point, and it was three times as slow as it was in their previous centralized setup.

Doesn’t work for everyone, and I don’t think it works in all circumstances. But it will work and scale with exceptional team members.

In case it interests you, we wrote a book about this experience and the tools we chose, which you can find here: http://leanpub.com/startupflow

Louis