It has become increasingly common for technology companies to run as Fully Distributed teams. That is, teams that collaborate primarily over the web rather than using informal, face-to-face communication as the main means of collaborating.
This has only become viable recently due to a mix of factors, including:
- the rise of “cloud” collaboration services (aka “web 2.0” software) as exemplified by Google Apps, Dropbox, and SalesForce
- the wide availability of high-speed broadband in homes that rivals office Internet connections (e.g. home cable and fiber)
- real-time text, audio and video communication platforms such as IRC, Google Talk, and Skype
Thanks to these factors, we can now run Fully Distributed teams without a loss in general productivity for many (though not all) roles.
In my mind, there are three models for scaling number of employees in a growing company in the wild today. These are:
- Vertically Scaled: Fully co-located team in a single office. Need more people? Get a bigger office. Communication is face-to-face preferred, digital as necessary. I suspect Dropbox operates this way right now with its new and huge primary office in San Francisco. In Web 1.0, most companies were scaled this way out of necessity.
- Horizontally Scaled: Several co-located teams in geographically separate offices. Communication is face-to-face preferred for employees in same office, digital preferred for employees in separate offices. I suspect Foursquare operates this way with offices in New York, San Francisco, and London.
- Fully Distributed: There is no dedicated, co-located office. Digital communication is preferred for all communication. Github, Automattic, 37 Signals, and Basho operate this way today.
Choice 1 is the most “traditional” scaling approach. The theory behind this approach is that face-to-face communication is the most efficient collaboration method. Nice offices are the best way to build team camaraderie and attract the best talent. It can be tempting when growing to switch from a Vertically Scaled team to a Horizontally Scaled one, by simply adding a second office location.
Choice 2 is typically how small, colocated teams end up becoming “semi distributed” teams via multiple offices connected via web-based collaboration tools. In other words, some companies that are going through growing pains under a Vertical model may switch to Horizontal as a coping mechanism. If there is a talent shortage in a Vertical team’s original headquarters location, or if enough office space cannot be procured to sustain employee growth, Choice 2 may be seen as the only option on the table.
Choice 3 is probably the rarest among growing technology companies today, but is, as I mentioned, increasingly common. In Fully Distributed teams, there is no real “headquarters” or “central office”. All communication is digital-preferred, which means employees can work from anywhere and not be fearful about out-of-band communication. Typically, employees will set up home offices or work out of coworking spaces in their home area. Occasionally, the team will still have a “headquarters” office, though this office will often be reserved for things like management, sales, marketing, business development, or other operational roles that do not need to be scaled as heavily.
Choice 3 tends to work extremely well for technology-heavy teams due to a few factors:
- Tools for doing distributed collaboration on software projects are very mature thanks to the open source community, which has been doing this at scale for years. To give just a few examples: source code control is web-based, hosted, and distributed (e.g. Github); all good project management or bug tracking tools are web-based; production systems can be effectively managed using SSH; team knowledge bases can be built effectively using wiki technology/conventions perfected by projects like Wikipedia; many web-based tools are available for all other forms of typical “office” collaboration such as document editing, file sharing, and instant messaging.
- Software engineering requires long periods of uninterrupted focus, aka Flow. Working in an office environment tends to involve lots of interruptions and meetings; working from home, by contrast, (assuming a separate home office) guarantees a high comfort level and long periods of concentrated work in private.
- Great software engineers have eccentric work habits and quirky computer setups. Many software engineers report getting their best work done between 10pm and 2am or between 7am and 9am. Many intensely dislike commutes and rigid work schedules. Most have heavily customized their personal development workstation to be greased for productivity. Many report getting some of their best ideas in the shower or after a nap. Working from home in a Fully Distributed model offers more opportunities to leverage their established (and optimized) work style which would be socially unpalatable in an office environment.
- The best software teams are merit-based. That is to say, success on a great software team is measured by working software, not by the number of hours the engineer has planted his or her butt in an office chair. Success is definitely not measured by the number of meetings you have held or the quantity of your communication. Fully Distributed technology teams make working software the only reasonable deliverable a team member can provide. Thus, these teams naturally self-organize around its most productive members and shine a spotlight on poor performers.
Related Reading
Github’s fully distributed team is described well in this GigaOM piece, Tales from the Trenches: GitHub. Zach Holman’s presentation, How Github Works, also provides an insider’s take. Github is interesting because though there are 77 employees and the team operates in “fully distributed” mode, there are a significant number of engineers at the company’s headquarters in San Francisco (perhaps as many as 30 by some reports).
The CEO of Automattic, the company behind WordPress.com, describes 5 reasons why your team should be (fully) distributed. They also discussed their distributed culture and collaboration environment on their team blog. This AllThingsD article points out that the company grew to over 100 employees and over $45 million/year in revenue with no central office.
Basho, the creators of the distributed database Riak, are a fully distributed team of nearly 75 employees, millions per year in revenue. An excellent blog post on Basho’s blog dated last year describes their distributed culture. The person who wrote that post also provided a breakdown of headcount by job function: Engineering/Support: ~20, Executive: ~6, Sales/Marketing: ~7, Admin: 1.
37 Signals founder DHH wrote about the technology “talent shortage” to “Stop whining and start hiring remote workers”. In it, he indicated that 37 Signals distributed team includes employees from: Fenwick (Canada), Phoenix (Arizona), Caldwell (Idaho), Romiley (UK), Jefferson Hills (Pensylvania), Ann Arbor (Michigan), Boulder (Colorado), and Tampa (Florida). Another great post from their blog talks about Equality and Remote Teams — noting a negative behavior that happens in Semi Distributed teams where remote workers are seen as “second-class” team members to those in the “primary” office, and what they did to eliminate this behavior.
Fully Distributed: is it fully viable?
I have heard many VCs and business school academics describe distributed teams as a big mistake. To me, this makes perfect sense. VCs and academics are themselves only in the early stages of seeing their own business models disrupted by distributed financing and distributed education. So long as there is still a strong premium placed on face-to-face interaction in their own fields, they will assume it holds true for other fields, as well.
Vertical/Horizontal Scaling are “proven” Web 1.0 techniques for growing companies (think of Google or Amazon), while Fully Distributed is as of yet unproven. VCs in particular like to remove whatever risk factors they can from deals — the Fully Distributed model seems like a risk with no corresponding upside, especially if capital is cheap and talent is widely available.
But perhaps the biggest reason for distrust of Fully Distributed teams is simply past (and out-dated) experience. VCs and business school academics are typically older. They have lived through an age where corporate America became obsessed with Information Technology and its hyped ability to virtualize and distribute all communications, even when Internet connections were slow/unreliable and collaboration software was beta-stage, at best. Thus, they associate digital collaboration tools with the slow/frustrating kludges of yesteryear. They have also not yet fully internalized the various ways in which Internet distributed models have beaten centralized/co-located models in advanced collaboration — some big examples here include Wikipedia and the Linux kernel.
Fully Distributed’s viability is a recent development — I suspect we only reached the threshold about 3 or 4 years ago. But believe me: we have reached it. It is now a fully viable model alongside the other two more traditional organization scaling models. And it will become increasingly common in the next few years as the tools get better and the option becomes accepted by the wider ecosystem.
Other fully distributed teams discovered since publication: MadMimi (25 employees, all work-from-home); Canonical (multi-timezone distributed team; run like large open source project); Mozilla (they call themselves “remoties”); StackOverflow (16 full-time remote, 18 in-person office, but fully distributed “DNA”); Buffer (25 work-from-home, some in SF, discussed in Washington Post)
UPDATE – 2019-01-02: I gave a talk about our fully distributed team at CTO Summit NYC in December, 2018. I’ll post a link to a video once it’s online; for now, the slides can be found here. Note that the above citations about mid-size fully distributed teams are dated to when this post was published in ~2012-2013; as of 2019, the most impressive examples are Elastic (staff of 1,200+, 100% fully distributed) and InVision (staff of 800+, 100% fully distributed). The model truly has scaled impressively, and become more pervasive.
This really resonates with me: we hesitated a long time before deciding to work as a fully distributed team (well “fully” may be a big word as we are currently 3), but I really don’t regret it, compared to synchronous workspaces where I was disturbed very often.
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
Did it for five years with a large team while building multiple companies. We got an office after the engineering team asked for it. And only then. Works great as a hub and spoke but there is an unfair advantage to being office crew sometimes.
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.
Fully distributed teams are not always working (therefore, can be “distrusted”) because it just doesn’t work for some people.
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.
we are almost totally distributed but we have a shared room full of racked machines for testing, development, etc.
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.
Choice 3 is how Canonical made Ubuntu. I’ve worked there for 6 years and love it. I want all my future work to be choice 3 🙂
I’ve been working in a Horizontally Scaled company for the past three years and I like the idea of having, at least, the IT teams separate from the business, specially for development teams.
On the other hand, when scaling either horizontally or distributed , as a developer, you’ll need support. Not on the coding side, but on how the business is run, in architecture, in what makes money and if the business is very complex, I don’t see a fully distributable approach working.
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.
I recently saw a presentation of a business being run by choice #3. Not software development, but an information processing business. There were a half dozen workers in four cities. Everyone worked from a home office. Dropbox was used for file sharing. Communications was mostly by email, as I recall. The business process was a queuing system, with each worker having an input and output queue. Status was easily tracked by monitoring the queues.
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.
Great comments here and on Hacker News. I’ll respond to just one of them that stuck out for me:
“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.
Hi,
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.
Hi,
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.
One of the dangers of horizontally scaled teams (i.e., option 2) is that the members fall into “us-and-them” thinking as the team becomes distributed over time. This is particularly an issue for teams that have grown through acquisition rather than organically. Co-located team members at the company’s headquarters over emphasize face-to-face communication and don’t put sufficient effort into digital communication with their distributed peers. This leaves everyone outside of headquarters “out of band”.
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).
@Benjamin Wesson, great comment. I agree 100%.
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.
Good post and comments.
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.
IBM and Cisco and the ilk are fully distributed. Being in a different physical location or a different timezone is about the same in terms of communication overhead.
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.
@Scott Yes, I’ve pondered this, as well.
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.
We are a startup with a fully distributed team- no head office. We are struggling with communication and software tools for scrum, kanban, scrumban- trying to figure out what works best for software development.
Does anyone have any recommendations- real time updates is key as our calls are on skype/ghangout.
Thanks!
I’m curious to learn what software tools people are using to manage their distributed teams. We haven’t found a good solution for real time development management- scrum/kanban/scrumban.
Any recommendations or experiences you can share- what works, what didn’t work?
Thanks!
I agree that fully distributed teams are still a future trend, but we’re slowly seeing more of it.
I’m a freelance tester, and I’ve worked with several distributed teams and I’ve seen a few things work well, and a few not so well.
A few things I’ve seen work well:
Occasional get-togethers for team building and planning.
Having new team members mentored by a senior member.
Daily status meetings (keep them short and sweet).
Use public collaboration tools – not VPN.
A good systems team that can do remote support and ensure security.
A few things I’ve seen not so well:
Micromanaging from afar – lots of tags, key & screen capture. Let them know you don’t trust them and make sure their “busy” instead of productive.
Everything is on the wiki – but you’ll never find it. But hey, it helps prevent chatter.
Remote planning meetings. Pay airfare and a conference room for 2-3 people and it will get done quicker.
Paying less. You can hire cheap labor (in India or elsewhere.) Or you can hire people who choose not to work in an office because they’re so good they don’t have to.
This thread has run an astonishingly long time. I have seen some changes lately that are discouraging. When I started out five years ago developing with a new, but very popular, environment (iOS), the demand was so great that distributed teams were almost a given. This was true even in 2012 when this article was published. And it worked well, at least for me, not to mention the projects I worked on.
But lately, as the pool of available iOS devs has increased, despite the still strong demand, I am seeing a swing back away from distributed teams to on-site, in-office requirements. This mostly in the name of effective “collaboration” (buzzword), particularly among startups. Many have no hesitation to off-shore some work, but require US employees to be on-site, often to manage the off-shore folks. I recently had a position that involved a two hour commute one way to go to the office, sit in my chair, and talk with/manage the off-shore folks in the morning, and work alone in the afternoon (timezone difference, and there were no other US devs). Then, I would drive two hours home in the evening.
There have been excellent points for discussion brought up here, and I hope to see this thread continue. For me, the productivity gains in distributed work are the best demonstration of efficacy. No wasted commute time, fewer distractions, focused work and communication all make me a better contributor. And getting to know your fellow team members and a little socializing is still possible.
Give me #3, and I will code happily ever after.